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1.  SYSTEM  CONTROL  FEASIBILITY  DEVELOPMENT  MODEL  IMPLEMENTATION 


1.1  System  Control  Modules 

The  Modular  System  Control  Development  Model  (MSCDM)  consists  of 
nine  functional  modules:  St  at i on-to-st at i on  Communications 
Intertace  (SSCI),  Voice  Service  Quality  Control  (VSQC) ,  Digital 
Service  Quality  Control  (DSQC),  Data  Base  Management  Service 
(DBMS),  Baseband  Signal  Analysis  and  Wide  Band  Signal  Analysis 
(BWBSA).  Operator  Control  and  Report  Interface  (OCRI),  Fault 
Isolation  and  Control  Coordination  (FIAC),  Switch  Data  Collection 
and  Analysis  (SDCA),  and  Simulated  Input  Generator  (SIG).  Each  of 
these  modules  i  ;  implemented  using  microcomputer  hardware  and 
software,  and  module  intercommunication  is  performed  via  a 
Burroughs  Loop  or  Ring  Architecture. 

1.1.1  SSCI 


The  St  at i on-to-st at  ion  Communication  Interface  (SSCI)  serves  as  a 
gateway  node  interface  to  loop  4  of  the  ESM.  The  loop  4  -  loop  5 
interface  implemented  is  9600  baud  asynchronous.  The  SSCI  is  used 
to  simulate  communication  between  different  system  control  sites. 
The  SSCI  performs  code  conversion,  intransit  queueing  and  packet 
routing . 
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1.1.2  VSQC 


The  Voice  Service  Quality  Control  (VSQC)  module  performs 
performance  assessment  of  voice  channels  for  the  purpose  of 

detecting  degrading  performance  and  assisting  in  fault  isolation. 
The  MSCDM  is  capable  of  monitoring  at  least  1000  channels.  By 
convention  channels  numbered  1-500  are  monitored  by  the  VSQC. 
There  are  six  parameters  to  be  checked  per  channel: 

1.  Peak  Power  (PK) 

2.  Average  Power  (AV) 

3.  Frequency  Oft  set  (FO) 

4.  Phase  Jitter  ( PJ ) 

5.  C-Message  Noise  (CN) 

6.  3  KHz  Flat  Noise  (FN) 

The  parameters  .ire  generated  by  the  Simulated  Input  Generator 

(SIG)  microcomputer.  Thresholding  is  done  on  the  parameters  by 
comparison  with  the  Ked  High  (RH),  Red  Low  (RL),  Amber  High  (AH), 

and  Amber  Low  (AL)  values  in  order  to  determine  whether  the 

channel  parameter  is  in  the  Red,  Amber  or  Green  region  as  shown  in 
Figure  1-1. 

The  parameter  thresholds  for  the  VSQC  are  given  in  Table  1-1. 


Table  1-1.  VSQC  Parameter  Thresholds 


Paramet er 

Kit 

RL 

AG 

AL 

Units 

PK 

10 

0 

8 

2 

dBmO 

AV 

10 

0 

8 

2 

dBmO 

FO 

20 

-100 

0 

-80 

Hz 

PJ 

10 

-90 

-10 

-70 

deg 

CN 

0 

-80 

-10 

-60 

dBmO 

FN 

20 

-100 

0 

-80 

dBmO 

The  VSQC  also  performs  trending  on  the  parameter  values. 
Threndmg  begins  when  the  parameter  is  within  a  delta  value  of  the 
Threshold.  The  critical  trending  values  for  the  VSQC  parameter 
thresholds  are  given  in  Table  1-2. 


Table  1-2. 

VSQC 

Critical 

Tr endi ng 

Values 

Parameter 

Delta 

RHT 

RLT 

AHT 

ALT 

PK 

0.5 

9.5 

0.5 

•7.5 

2.  5 

AV 

0.5 

9.5 

0.5 

7.5 

2.  5 

FO 

3 

17 

-97 

-3 

-77 

PJ 

2 

8 

-88 

-8 

-68 

CN 

1 

-1 

-79 

-19 

-59 

FN 

2 

18 

-98 

-2 

-78 

The  threshold  and  trending  values  may  be  modified  by  modifying  the 
program  DATA  statement  and  recompiling  the  VSQC  nodal  software. 

Event  Reports  are  sent  to  the  FIAC  when  a  parameter  value  is  Amber 
or  red  and  the  Event  Reporting  condition  parameter  is  turned  ON 
(via  Module  Update  Mode  3  of  the  User  Language).  Event  Repoi  ts 
consists  of  an  8-byte  trunk  name,  4-byt.e  channel  number,  one-byte 
condition,  one-byte  parameter  number  that  caused  the  Red  or  Amber 
condition,  3-byte  monitor  point  number,  and  the  node  designator  to 
which  reports  should  be  sent. 


The  VSQC  interprets  commands  from  the  DBMS  generated  by  Mode  3  of 
the  User  Language.  The  commands  include  Event  Reporting  ON  or 
OFF;  if  ON  the  node  designator  to  which  the  Event  Reports  are  to 
be  sent,  i.e.,  the  terminal  used  for  display,  is  given.  The  VSQC 
also  interprets  the  command,  received  as  a  packet  from  the  loop, 
to  measure  a  specific  channel  which  is  sent  to  the  SIG;  the 
resulting  measurement  value  is  sent  to  the  OCRI  terminal 
requesting  the  measurement  (via  Mode  3  of  the  User  Language). 

1.1.3  DSQC 


The  Digital  Service  Quality  Control  (DSQC)  module  assesses  the 
performance  of  digital  data  channels  for  the  purpose  of  detecting 
degrading  performance  of  these  channels  with  respect  to  increasing 
error  rates,  and  to  assist  in  fault  isolation.  Channels  numbered 
501-1000  are  arbitrarily  monitored  by  the  DSQC.  There  are  three 
parameters  to  be  checked  per  channel: 

1.  Pseudo  Error  Rate  (PE) 

2.  Bit  Error  Rate  ( BIE ) 

3.  Block  Error  Rate  (BLE) 

The  parameters  are  generated  by  the  SIG.  The  parameter  thresholds 
for  the  DSQC  are  given  in  Table  1-3. 


Table  1-3.  DSQC  Parameter  Thresholds 


Parameter 

RH 

RL 

AH  AL 

Units 

PE 

10 

-10 

5  -5 

% 

BIE 

10 

-10 

5  -5 

% 

BLE 

10 

-10 

5  -5 

% 

Trending 

occurs  when 

the 

parameter 

value  is  within  one  of 

the  red 

threshold 

,  or  two  of 

the 

AMBER 

thresholds.  Event  reports 

are  sent 

to  FI AC 

using  the  same 

format 

as 

described  for  VSQC. 

The  DSQC 

interprets  the  same  commands  generated  by  the  DBMS  as  the  VSQC. 

1.1.4  DBMS-PDU 

The  Data  Base  Management  Service  (DBMS)  performs  the  data  base 
maintenance  functions.  It  maintains  the  display  files  for  the 
human  interface  User  Language,  system  configuration  files, 
equipment  status  files,  and  object  files  for  the  various  modules. 
The  User  Language  runs  on  the  DBMS  and  is  used  to  control  the 
system.  Mini  disks  are  used  to  store  the  various  files.  The  DBMS 
may  also  be  used  as  a  Program  Development  Unit  (PDU)  with  a  local 
CRT  terminal  when  not  being  used  for  the  MSCDM  application.  The 
PDU  develops  and  maintains  software  for  the  MSCDM.  The  PDU  runs 
the  RT-11  Operating  System  and  it  may  be  used  as  a  general  purpose 
processor. 


1.1.5  OCR  I 


The  Operator  Control  and  Report  Interface  (0CR1 )  performs  the 
functions  ol  interfacing  to  the  site  operator.  The  User  Language 
interface,  when  the  OCR1  terminal  is  ATTACHED  to  the  DMBS  node, 
allows  the  operatoi  to  control  the  site,  request  status  informa¬ 
tion  concerning  site  and  equipment  performance  and  prepare  site 
reports  which  are  forwarded  to  other  sites  such  as  a  simulated 
ACOC.  operator  *o  operator  messayes  are  also  ;;uppoi  t  ed  by  the 
User  Lanquaqe.  The  OCR  l  terminal  can  be  used  to  print  event 
reports,  lault  rebuts,  and  alarms  lot  the  simulated  equipment 
qetuH.it  ed  by  the  K 1  AC  and  SDCA  modules,  and  ett  01  messayes  con- 
eerniny  the  EDM  itsell  yenerated  by  the  nodal  modules  (e.y., 
Uiop-Back  in  etlect,  queue  overflow). 

1.1.6  HWBSA 

The  Hast'  Hand  Si  qua  1  Analysis  and  Wide  Band  Siqnal  Analysis 
(HWBSA)  module  pel  lot  ms  per 1  ormanco  assessment  on  link  equipnent  . 
Three  link'-,  ai  e  moni  ton’d.  There  are  seven  parameters  to  be 


checked  pet  link  lot  the  baseband: 

Un  1 1  s 

1.  Transmitter  Percent  Modulation  (BTPM)  * 

2.  Transmit  tot  Frequency  Deviation  (BTFD)  H«. 

3.  Relative  Transmitter  Power  (BRTP)  dBmO 

4.  Receiver  AOC  Vo  It  aye  ( BRAV)  IX-  Volts 

5.  Receiver  IE  Output  (BRIO)  DC  Volts 

6.  Multiplex  Baseband  Levels  (BMBL)  dBmO 

7.  Multiplex  Pilot  Levels  (BMPL) 
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dBmO 


There  are  six  parameters  for  the  wideband: 


8.  Transmitter  Percent  Modulation  (WTPM) 

9.  Transmitter  Frequency  Deviation  (WTFD) 

10.  Relative  Transmitter  Power  (WRTP) 

11.  Receiver  AGC  Vo 1 1 aqe  (WKAV) 

12.  Receiver  IF  Output  (WRIO) 

11.  Multiplexor  Pseudo  Errot  Rate  (WMPE) 


Un  it  s 
* 

HZ 

dllinO 

DC  Volts 
DC  Volts 


The  parameter  thresholds  tor  the  three  links  are  qiven  in  Table 
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The  parameters  are  generated  by  the  S1G.  In  addition,  alarms  are 
generated  associated  with  the  three  links  for  transmitters, 
receivers,  and  multiplexors.  Alarms  and  Red  and  Amber  threshold 
values  are  sent  to  the  FIAC  as  Event  Reports.  Event  Reports 
consist  of  one-byte  link  number,  2-byte  baseband  number,  2-byte 
wideband  number,  one-byte  supergroup,  one-byte  group,  one-byte 
condition,  2-byte  parameter  number  that  caused  the  Red  or  Amber 
condition,  a  3-byte  monitor  point  number,  and  the  node  designator 
to  which  reports  should  be  sent. 

The  BWBSA  interprets  commands  from  the  DBMS  similar  to  the  VSQC 
and  DSQC  except  that  measurements  are  performed  tor  3  links  rather 
than  channels. 

1.1.7  E I  AC 

The  FauLt  Isolation  and  Control  Coordination  (FIAC)  module  inter¬ 
prets  Event  Reports  and  Alarms  from  the  VSQC,  DSQC,  and  BWBSA 
modules  for  the  purpose  of  isolating  the  equipment  causing  the  de¬ 
tection  of  a  fault  condition.  Amber  and  Red  Event  Reports  are 
received  by  the  FIAC  and  retransmitted  to  the  destination  Node 
Designator  tor  OCRI  reporting  and  to  the  DBMS  in  order  to  update 
the  Equipment  Status  File.  The  OCRI  operator  can  display  and 
modify  the  Equipment  Status  File  via  Mode  6  of  the  User  Language. 
Red  Event  Reports  are  reported  only  once  when  the  equipment  first 
fails  although  subsequent  measurements  will  also  result  in  the  Red 
Region. 
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The  FI  AC  analyzes  Hie  Red  Event  Reports  for  fault,  indications  and 
initiates  isolation  procedures  to  resolve  to  the  equipment  level 


I 

1 

the  location  of  the  fault.  The  FIAC  checks  the  connectivity 


through  the  network.  For  the  delivered  MSCDM ,  the  assumed  con¬ 
nectivity  between  the  VSQC,  DSQC  and  BWBSA  is  given  in  Table  1-5. 

Table  1-5.  FDM  Assumed  Connectivity 

Monitor  Po ints 
1-333 
334-666 
667-1000 

The  FIAC  collects  Red  Event  Reports  and  assigns  them  to  the 
various  connectivity  groups.  When  a  connectivity  group  lias  a  Red 
Event  Report  from  VSQC,  DSQC  and  BWBSA,  the  monitor  points  are 
compared  to  determine  the  equi pment  causing  the  fault.  The  lowest 
monitor  point  indicates  the  equipment  causing  the  fault.  Fault 
Reports  are  then  sent  to  both  the  local  OCR1  terminal  and  a  remote 
site  OCRI.  The  Fault  Report  contains  the  monitor  points,  link  and 
channel  numbers  for  the  connectivity  group.  The  FIAC  software 
contains  variables  used  to  specify  the  Node  Designators  tor  the 
Local  and  Remote  destinations  for  Fault  Reports.  The  default, 
nodes  are  the  OCRI  terminal  for  Local  Fault  Reports  and  the  CRT 
terminal  in  loop  4  for  Remote  Fault  Reports. 


Con n e c t v  v i t  y  G roup 
Area  1 
Area  2 
Area  3 


In  the  MSCDM,  software  resides  on  the  SDCA  node  to  simulate  the 
behavior  of  a  remote  FIAC.  Area  1  is  used  to  represent  the  area 
associated  with  the  MSCDM  FIAC.  Area  2  is  used  to  represent  the 
area  associated  with  the  remote  FIAC  (as  simulated  by  SDCA).  Area 
3  is  used  to  simulate  other  areas  for  which  faults  cannot  be 
isolated  by  the  FIAC.  The  SDCA  sends  occasional  random  Event 
Reports  t.o  FIAC  with  Monitor  Points  in  Area  1.  FIAC  sends  Event 
Reports  to  SDCA  for  those  Event  Reports  received  from  VSQC,  DSQC, 
and  BWBSA  with  Monitor  Points  in  Area  2.  When  Red  Event  Reports 
are  collected  for  the  VSQC,  DSQC,  and  BWBSA,  faults  can  be 
isolated  and  reported  for  Areas  1  and  2  but  cannot  be  isolated  for 
Area  3.  The  faults  that  cannot  be  isolated  are  reported  to  local 
and  remote  oCRI's  via  a  Fault  Report. 


1.1.8  SDCA 


The  Switch  Data  Collection  and  Analysis  (SDCA)  module  receives 
switch  traffic  data  generated  by  AUTODIN  or  AUTOVON  switches,  and 
perforins  loading  assessments  on  this  data  to  detect  switch  equip¬ 
ment  saturation  conditions.  Traffic  flow  control  computations  and 
actions  are  performed.  Simulated  data  to  represent  two  switches 
is  generated  by  the  PDP  11/40  in  loop  2.  A  switch  condition 
report  is  sent  by  the  PDP  11/40  to  the  SDCA  approximately  every 
2.5  seconds.  The  switch  condition  report  consists  of  16  fields  as 
given  in  Table  1-6. 


Table  1-6.  SDCA  Switch  Condition 

Report 

Critical 

Values 

Field 

Description 

AUTODIN 

AUTOVON 

1 

Switch  # 

1 

2 

2 

#  of  Transactions 

512 

256 

3 

1  of  Blocked  Transactions 

25 

10 

4 

Transaction  Queue  Depth 

25 

10 

5 

#  of  Prescripted  Transactions 

10 

25 

6 

Trunk  Group  Occupancy 

50 

40 

7 

Trunk  Group  Overflow 

50 

40 

8 

Message  Delay  (sec.) 

10 

5 

9 

Maximum  Message  Aye  (sec.) 

10 

5 

10 

Number  of  Overflow  Messages 

10 

10 

11 

#  of  Senders 

128 

64 

12 

#  of  Markers 

128 

64 

13 

#  of  Receivers 

128 

64 

14 

#  of  Pooled  Crypto  Units 

128 

64 

15 

Service  Time  for  Dial  Tone  (sec.) 

10 

5 

16 

Service  Time  for  Crypto  Unit  (sec.) 

10 

5 

Whenever  a  critical  value  of  Table  1-6  is  exceeded  and  the  Event 
Reportiny  Condition  Parameter  is  ON,  the  switch  is  considered  to 
be  in  a  saturated  condition  and  Red  Event  Reports  are  sent  to  the 
DBMS  Status  File  and  the  destination  Node  Designator  for  OCRI 
reportiny . 


The  SDCA  interprets  commands  from  the  DBMS  similar  to  the  VSQC, 
DSQC  and  BWBSA  except  that  measurements  are  performed  for  2 
switches  rather  than  channels  or  links. 


1.1.9  SIG 


The  Simulated  Input  Generator  (SIG)  is  a  microprocessor  that 
generates  simulated  inputs  to  the  VSQC,  DSQC,  and  BWBSA  modules. 
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It.  acts  as  both  a  communications  sensor  and  a  scanner.  It  is  used 
to  simulate  the  measurements  performed  on  1000  channels  and  3 
links,  multiplexors,  transmitters,  and  receivers.  Random  numbers 
are  generated  for  the  measurements  for  the  Red,  Amber,  and  Green 
regions.  Approximately  10%  of  the  measurements  are  in  the  Amber 
region  and  5%  in  the  Red  region.  The  SIG  continually  writes  to 
three  9600  baud  interfaces  for  the  VSQC,  DSQC  and  BWBSA.  Each 
channel  and  link  is  simulated  by  a  measurement  report  that  is 
written  to  the  interface.  A  VSQC  measurement  report  consists  of 
the  six  parameters  given  in  Table  1-1  plus  the  channel  number, 
trunk  name,  and  monitor  point.  A  BWBSA  measurement  report  con¬ 
sists  ot  the  thirteen  parameters  given  in  Table  1-4,  plus  the  link 
number  and  monitor  point.  In  addition,  Multiplexor,  Transmitter, 
and  Receiver  Alarms  are  generated. 

The  SIG  also  responds  to  commands  from  the  VSQC,  DSQC  or  BSBSA  to 
perform  a  measurement  on  a  specific  channel  or  link.  Equipments 
which  are  in  the  Red  region  continue  to  generate  Red  measurement, 
parameters  for  a  specified  number  of  successive  measurements  in 
order  to  simulate  hard  equipment  failures  and  repair  time. 

1.1.10  Module  Interconnection 

The  human  interface  to  the  MSCDM  is  via  the  OCRI  terminal.  The 
OCRI  node  is  normally  ATTACHED  to  the  DBMS  which  runs  the  User 
Language.  The  DBMS  responds  to  the  ORCI  node  and  any  other  ESM 


terminal  in  the  other  loops.  Interloop  communication  is  done  via 
the  SSCI  node.  The  SIG  generates  measurement  reports  to  the  VSQC, 


DSQC ,  and 

BWBSA. 

The  PDP  11/40 

in 

loop  2  generates 

switch 

saturation 

reports 

to  the  SDCA. 

The 

DBMS  via  Mode  3 

( Module 

Update)  of  the  User  Language  sends  commands  to  the  VSQC,  DSQC, 
BWBSA,  and  SDCA.  The  DBMS  via  Modes  1  and  5  (CRT-to-CRT,  Report) 
sends  messages  to  other  loops  v.^.  he  SSCI.  The  VSQC,  DSQC,  and 
BWBSA  send  Event  Reports  and  alarms  to  the  FIAC.  The  FIAC  sends 
Bvent  Reports,  Alarms,  and  Fault  Reports  to  the  DBMS  Status  File 
and  the  OCRI .  The  SDCA  sends  Switch  Saturation  Reports  to  the 
DBMS  Status  Fi le  and  the  OCRI.  All  nodes  send  Nodal  Error  Reports 
(e.g.  Queue  Overflow)  to  the  OCRI.  The  SDCA,  functioning  as  a 
remote  FIAC,  sends  and  receives  Event  Reports  to  FIAC. 

1.2  Alternatives  and  Cost  Benefits 

Prior  to  the  start  of  the  MSCDM  Phase  II  implementation  effort,  a 
decision  was  made  to  utilize  the  LSI- 11  microprocessor  as  the 
basic  system  control  module.  The  modules  are  connected  together 
by  means  of  a  fail-soft  loop  or  ring  communications  network.  This 
decision  was  made  by  the  government  based  upon  the  results  of  the 
MSCDM  Phase  I  study  effort.  The  alternative  analysis,  cost 
benefits,  and  description  of  the  recommended  family  of  system 
control  modules  are  given  in  the  MSCDM  Phase  I  Final  Report  (9). 
A  decision  was  made  early  in  the  project  to  utilize  the  newer 
LSI-11/2  microcomputer  module  rather  than  the  older  LSI-11  module 
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for  all  nodes  except  the  DBMS-PDU.  The  PDU  is  a  packaged  PDP11V03 
containing  the  older  LSI-11  module.  The  LSI-11/2  is  half  the  size 
of  the  LSI-11.  The  LSI-11/2  with  64K  Bytes  of  memory  takes  the 


same  backplane  space  as  the  LSI-11.  As  a  result  the  LSI-11/2 
costs  less  and  consumes  less  power.  The  backplanes  used  for  MSCDM 
can  accomodate  both  the  LSI-11  and  LSI-11/2  processor.  The  back¬ 
plane  used  contains  eight  double  height  module  slots.  An  MSCDM 
node  with  the  LSI-11/2  uses  six  of  these  slots  thus  there  are  two 
spare  slots  per  node. 

The  Loop  Interface  Unit  (LIU)  -  LSI-11  Interface  Card  is  the  most 
significant  development  item  in  the  project.  A  decision  was  made 
to  provide  a  Direct  Memory  Access  (DMA)  type  of  interface  rather 
than  a  simplier  programmed  I/O  interface.  The  DMA  interface  is 
the  fastest  method  of  transferring  data  between  the  LSI-11  memory 
and  the  I/O  buffers  on  the  LIU.  The  DMA  interface  increases  the 
throughput  of  the  node  since  the  processor  spends  less  time 
handling  I/O  from  the  loop.  The  DMA  interface  costs  slightly  more 
than  a  comparable  programmed  I/O  interface,  and  it  is  contained  on 
a  general  purpose  wire-wrap  board  that  uses  two  backplane  slots. 
The  LIU-LSI-11  Interface  Card  is  connected  to  the  LIU  via  back¬ 
plane  wires  for  all  nodes  except  the  DBMS  node  which  is  connected 
via  a  10  foot  interface  cable. 
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The  OCR  I  terminal  used  for  the  MSCDM  is  a  hard-copy  keyboard 
printer  (LA36  DEC  writer).  This  was  chosen  rather  than  a  CRT 
terminal  since  the  ESM  system  currently  has  no  hard  copy  terminals 
connected  directly  to  the  loops.  The  ESM  CRT  terminals  can  be 
ATTACHED  to  the  DBMS  und  used  as  OCRI  terminals.  Also,  a  CRT 
terminal  (VT52)  can  be  connected  to  the  OCRI  node  by  modification 
of  the  Serial  Interface  Card  (DLV11)  for  the  9600  baud  CRT  rather 
than  the  300  baud  DEC  writer. 

The  Loop  4-Loop  5  interface  is  a  9600  baud  asynchronous  serial 
interlace.  Tins  is  different  than  the  other  inter  loop  interfaces 
which  use  a  special  Gateway  Interface  Board  that  operates  at  0.5 
Meyabaud.  Experience  with  ESM  usiny  many  inter  loop  transfers 
(e.y.,  Kile  Transfers)  indicates  that  the  Gateway  Interface  Card 
reliability  is  less  than  desirable.  It  is  anticipated  that  the 
asyncht onous  interface  between  Loop  4  and  5  will  provide  more 
reliable  inter  loop  communication.  The  asynchronous  interface  also 
has  cost  benefits  since  the  hardware  and  software  are  off-the- 
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2.  EXPERIMENTAL  TEST  PLAN 


2.1  System  Control  Experiments 

2.1.1  DCS  Hierarchy  Network  Configurations 

The  DCS  System  Control  Hierarchy  is  shown  in  Figure  2-1.  MSCDM  is 
primarily  concerned  with  defining  modules  for  the  lower  three 
levels  (Sector,  Nodal,  Station).  The  goal  is  to  define  a  set  of 
modules  that  can  be  applied  to  the  lowest  level,  and  enhanced  with 
additional  modules  to  be  applied  to  the  higher  levels.  The  ESM 
Multiloop  Network  can  be  used  to  simulate  DCS  Hierarchy  Network 
Configurations.  The  various  loops  or  host  processors  can  be  used 
to  simulate  sites  at  the  different  levels.  Where  hardware/ 
software  simularities  exist  between  the  ESM  and  operational 
systems,  actual  operational  software  can  be  run  on  the  host  pro¬ 
cessors.  For  example,  the  ATEC  program  is  using  PDP  11/70  and 
LSI-11  processors.  Subsets  of  the  operational  software  can  be 
modified  to  run  on  the  ESM  hardware.  The  heterogeneous  nature  of 
the  ESM  provides  a  large  amount  of  flexibility  and  capability  for 
testing  and  simulating  operational  software  for  the  various  DCS 
levels.  The  gateway  nodes  in  ESM  provide  protocol,  data  rate, 
code,  and  security  isolation  between  the  various  ESM  loops. 
Experiments  can  be  done  where  processors  of  different  levels 
communicate  with  each  other  on  a  periodic  basis;  when  a  remote 
processor  fails  to  respond  the  processor  initiating  the  Are  You 
There?  message  can  take  over  the  functions  of  the  remote 


processor . 


Figure  2-1.  DCS  SYSCON  Hierarchy 


Failures  can  be  simulated  and  the  resulting  reporting  sequence  can 
be  studied  as  reports  ripple  up  through  the  System  Control  levels 
using  ESM  host  processors  and  their  peripherals  as  the  different 
level  hosts.  The  statistics  of  traffic  and  delay  time  during  the 
reporting  sequence  can  be  measured  and  studied.  The  reports  can 
be  displayed  on  either  loop  connected  or  host  processor  connected 
peripherals  and  simulated  operational  direction  messages  can  be 
generated  and  rippled  down  through  the  System  Control  levels.  The 
controller  actions  required  can  be  investigated.  Alternate 
procedures  requiring  human  decision  and  initiation  can  be 
compar  ed . 

System  Control  Center  interaction  experiments  can  be  performed. 

The  interaction  involved  in  isolating  faults  and  removing  equip¬ 
ment  from  service  between  two  centers  can  be  examined.  This  would 
involve  the  Fault  Isolation  and  Analysis  Coordination  (FIAC) 
module  of  MSCDM  Loops  and  a  similar  program  running  on  a  host 
processor.  Various  fault  isolation  algorithms  can  be  studied. 

The  tasks  associated  with  this  area  include  the  identification  of 
similarities  between  the  ESM  and  operational  systems.  This  would 
be  a  research-oriented  task  involved  with  study ing  existing  software. 
The  software  would  then  be  modified  to  run  on  the  ESM.  Remote 
backup  processor  experiments  would  be  designed  and  implemented  in 
ESM  software.  Reporting  sequences  would  be  investigated  and  imple¬ 
mented  in  ESM  software.  The  tasks  associated  wit  It  DCS  Hierarchy 
Network  Configurations  involve  research  into  existing  systems  and 
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software  implementation  on  KSM.  The  cost  associated  with  this 
area  can  be  given  in  teims  of  man-months  for  research  oriented 
personnel  for  the  investigative  tasks  and  proqrammers  for  the 
implementation  tasks. 

The  tasks,  cost  qiven  as  man-month  estimates,  and  type  of  effort 
for  DCS  Hierarch  Network  Configurations  are  qiven  in  Table  2-1. 

Table  2-1  IK'S  Hierarchy  Netwoik  Con t  iqut  at  ion  Tasks 

Task  Man  Months  Kf for t 

Identify  Simulat  rlies  between  KSM  and 

Operational  Systems  S  Reseat  ch 

Modify  Operational  Software  for  KSM  4  Software 

Remote  Backup  Processoi  Design  t  System  Design 

Remote  Backup  Processor  Implementation  1  Softwate 

Reporting  Sequence  Investigation  t  Research 

Reporting  Sequence  Implementation  t  Softwate 

Fault  Isolat  ion  Algol  i  t  hm  Ident  il  icat  ion  t>  Research 

Fault  Isolation  Algorithm  Implementation  S  Software 

2.1.2  Distributed  Data  Base 

The  KSM  currently  has  a  distt  United  data  base  consisting  of 
circuits  and  trunks  on  the  PDF  11  4B  host  pt  ooessoi  s  using  t  hr' 
TOTAL  Data  Base  Management  System.  Kxpei  intent  at  ton  can  be  jtei  - 
formed  in  which  the  KSM  is  conf  igured  as  t  hr'  vat  tons  levels  rtf  a 
System  Control  hierarchy  with  representative  data  bases  at  each 
level.  System  Control  data  base  partitioning  studies  can  then  be 
performed  t o  examine  the  tradeoffs  between  secondary  st o  age 


requirements  and  access  times  to  the  distributed  data  base  as  a 
function  of  network  traffic.  Data  Base  Management  Systems  other 
than  TOTAL  can  be  used  and  compared.  The  use  of  a  non-data  base 
management  processor  (e.g.,  B776)  as  a  back-up  for  the  distributed 
data  can  be  investigated. 

The  tasks  associated  with  the  Distributed  Data  Base  area  include 
data  base  identification  of  existing  DCS  systems.  A  data  base 
partitioning  study  would  be  performed  resulting  in  the  design  and 
implementation  ol  a  distributed  data  base  similar  to  that  of  the 
existing  DCS  systems.  The  use  of  a  non-data  base  management 
processor  as  a  back-up  would  be  designed  and  implemented  using  ESM 
software. 

The  tasks  involved  with  Distributed  Data  Base  are  given  in  Table 

2-2. 


Table  2-2  Distributed  Data  Base  Tasks 


Task 

Man  Mont  hs 

Effort 

Data  Base  Identification  for 

Existing  DCS  Systems 

6 

Research 

Data  Base  Partitioning  Study 

3 

Research 

Data  Base  Partitioning  Design 

3 

Software 

Des  ign 

Data  Base  Partioning  Implementation 

4 

Software 

Back-up  Non-DB  Proc.  Design 

4 

Software 

Des  ign 

Back-up  Non-DB  Proc.  Implementation 

3 

Software 
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2.1.3  ATEC  Software  Tests 


The  software  being  developed  for  the  ATEC  program  can  be  tested 
and  evaluated  on  the  ESM  Multi loop  Network.  Since  the  ATEC  System 
will  utilize  PDP  11/70  and  LSI-11  hardware  it  is  anticipated  that  the 
software  developed  would  run  on  certain  ESM  processors  with  little 
modification.  Trending,  alarm  thresholding,  and  fault  isolation 
algorithms  can  be  run  on  the  ESM  processors;  processing  delay 
times  and  partitioning  methods  can  bo  studied.  Various  algorithms  can 
be  distributed  on  a  sot  of  microcomputers  and/or  minicomputers; 
the  degree  of  coupling  can  be  studied. 

The  tasks  associated  with  ATEC  Software  Tests  would  include  identi¬ 
fying  the  ATEC  software  to  he  tested,  modifying  the  software  for 
ESM,  and  then  evaluating  and  testing  the  software  along  with  the 
development  of  any  support  software  that  may  be  necessary  (e.g., 
special  simulators,  timing  software).  The  tasks  are  described  in 
Table  2-3. 


Table  2-3  ATEC  Software  Test  Tasks 


Task 


Man-Months  Effort 


Identification  of  ATEC  Software  to 
be  tested 


6  Research 

5  Software 

3  Software 


Software  Modification 
Support  Software  Development 
Testing  and  Evaluation 
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Soft  wa  i  e 


2.1.4  Interoperability 


Interoperability  between  various  systems  (e.g.,  DCS/TRI-TAC)/NATO) 
can  be  studied.  The  heterogeneous  nature  of  the  ESM  makes  it 
ideal  for  this  application.  Various  networks  can  be  interfaced  to 
the  nodal  microprocessors.  Protocols  can  be  programmed  into  the 
nodes;  hardware  interface  cards  of  various  types  are  available. 
Current  interfaces  include  Synchronous,  Asynchronous,  AUTODIN  II, 
SDLC ,  TCCF ,  and  IEEE  488.  Protocol  interfacing  between  the 
various  systems  can  be  examined.  Different  System  Control 
policies  in  the  various  networks  can  be  examined  and  integrated. 

Interoperability  tasks  include  identification  of  the  characteris¬ 
tics  of  systems  to  be  studied,  special  software  development  on 
both  the  protocol  level  and  the  I/O  handler  level,  and  possible 
hardware  interface  card  development.  The  tasks  are  described  in 
Table  2-4. 


Table  2-4  Interoperability  Tasks 


Task 

Man-Months 

Effort 

Identification  of  char acter isitics 
of  systems  to  be  studied 

5 

Research 

Protocol  level  software  development 
(per  interface) 

2 

Software 

I/O  Handler  software  development 
(per  interface) 

2 

Software 

Interface  card  development 
(per  interface) 

3 

Hardware 
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Interface  card  material  cost  is  estimated  at  $200  per  interface. 
Interface  card  assembly  labor  is  estimated  at  two  man-days  per 
interface . 

2.1.5  CRU 

The  Channel  Reconfiguration  Unit  (CRU)  can  be  studied  on  the 
ESM.  Channels  may  be  simulated  by  either  the  gateway-to-gateway 
links  or  the  links  between  nodes  on  a  loop.  Link  failures  can  be 
simulated,  and  automatic  reconfiguration  algorithms  that  utilize 
the  multiloop  alternate  routing  capability  can  be  performed. 
Routing  algorithms  can  be  studied.  Processor  stand-by  experiments 
can  be  performed  where  a  back-up  processor  will  perform  the  tasks 
of  a  failed  processor.  Failure  reporting  and  back-up  processor 
start-up  procedures  can  be  examined. 

The  application  of  the  CRU  problem  to  ESM  would  be  investigated  in 
order  to  determine  reconfiguration  and  processor  stand-by  algor¬ 
ithms  that  could  be  implemented  for  ESM.  The  CRU  tasks  are 
described  below  in  Table  2-5. 

Table  2-5  CRU  Tasks 

Task  Man-Months 

Application  of  CRU  to  ESM 

Investigation  5 

Reconfiguration  Algorithm  Implementation  3 

Processor  Stand-By  Implementation  3 


Effort 

Research 

Software 

Software 
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2.1.6  SENET 


The  Slotted  Envelope  Network  (SENET)  Concept  (1)  developed  at  DCA 
is  involved  with  the  integration  of  voice  and  data  switching.  An 
integrated  voice/data  system  is  characterized  by  two  classes  of 
traffic  (2).  Class  I  traffic  is  characterized  by  long  messages 
requiting  continuous  real-time  delivery  such  as  voice,  facsimile, 
or  low-speed  video.  The  call  is  either  accepted  or  blocked;  once 
accepted,  it  is  maintained  as  a  virtual  circuit  for  the  duration 
of  the  call.  Class  II  traffic  consists  of  either  short,  discrete, 
interactive  data  messages,  or  longer  stor e-and-f or  ward  type  data 
messages.  This  type  of  traffic  is  accepted  for  transmission  and 
may  experience  queueing  delay  as  it  travels  through  the  network 
(3). 

The  ESM,  with  its  currently  programmed  Newhall  loop  protocol,  is 
best  suited  for  Class  II  traffic.  The  Newhall  protocol  utilizes  a 
special  control  packet  called  a  Write  Token  (WT)  which  continually 
orbits  the  loop.  When  the  WT  is  detected,  a  node  may  write  one 
packet  (at  most  256  bytes)  onto  the  loop  followed  by  the  WT.  The 
current  ESM  may  be  best  described  as  a  packet  switching  network. 

Since  the  nodal  microprocessors  are  programmable,  other  types  of 
protocols  could  be  programmed  for  a  hybrid  approach  in  which  both 
circuit  switched  and  packet  switched  traffic  share  the  loop.  A 
special  Resource  Allocator/Scheduler  node  can  be  used  to  set  up 


-27- 


virtual  network  paths  between  any  two  nodes  on  the  loop  so  that 
the  long  Class  I  conversations  can  take  place.  Depending  on  the 
location  of  the  nodes  that  wish  to  communicate,  multiple  conver¬ 
sations  can  concurrently  take  place  on  the  loop. 

Another  approach  would  be  to  use  separate  loops  for  Class  I  and 
Class  II  traffic.  The  Jafari  loop  architecture  (4)  may  be  ideal 
for  this  application.  This  architecture  is  given  in  Figure  2-2. 
The  inner  control  loop  is  similar  to  the  ESM  loops.  The  outer 
data  loop  is  a  segmented  switched  loop.  The  inner  loop  can  be 
used  for  Class  II  traffic  and  to  request  circuits  for  Class  I 
traffic.  The  loop  controller  node  schedules  Class  I  traffic 
conversations  between  nodes  on  the  data  loop.  The  various 
switches  are  set  so  that  a  circuit  connects  the  nodes  having  the 
conversation.  The  ESM  would  have  to  be  enhanced  to  provide  the 
outer  data  loop. 

The  tasks  for  SENET  are  described  below  in  Table  2-6. 

Table  2-6  SENET  Tasks 


Task 

Man-Months 

Effort 

Loop  Protocols  Investigation  for 
Integrated  Voice/Data 

5 

Research 

Resource  Allocator/Scheduler 
Implementation 

4 

Software 

Jafari  Loop  System  Design 

4 

System  D 

Jafari  Loop  Hardware  Implementation 

6 

Hardware 

Jafari  Loop  Software  Implementation 

5 

Software 
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The  material  cost  for  the  Jafari  Loop  interface  is  estimated  at 
$300  per  node.  The  assembly  labor  for  the  Jafari  loop  interface 
is  estimated  at  two  man-days  per  node. 

2.1.7  Satellite  Control 

The  ESM  can  be  used  to  study  the  interface  between  the  Defense 
Satellite  Communications  System  (DSCS)  System  Control  and  DCS 
System  Control.  A  major  upgrade  of  DSCS  System  Control  is  planned 
using  automation  to  improve  status  monitoring,  reporting,  and 
commanding  (5).  This  improved  DSCS  System  Control  program  is 
called  RTACS  (Real-Time  Adaptive  Control  System)  (6).  RTACS 
supports  the  DSCS  as  System  Control  supports  the  DCS.  RTACS  is  a 
distributed  hierarchical  system  consisting  of  three  conceptual 
elements:  1)  Operational  Control  Element  (OCE);  2)  Network 

Control  Element  ( NCE)  and  3)  Terminal  Control  Element  (TCE). 

These  elements  interface  with  the  levels  of  the  DCS  System  Control 
hierarchy.  For  example,  the  OCE  interfaces  with  the  DCS  DCAOC. 

The  ESM  can  be  used  to  simulate  the  interactions  between  the  RTACS 
elements.  Various  nodes  can  perform  the  functions  of  the  OCE, 

NCE,  and  TCE.  The  interactions  between  RTACS  and  the  DCS  System 
Control  Elements  can  be  studied.  The  distributed  RTACS  software 
can  be  tested  on  the  ESM.  The  ESM  can  also  be  used  to  simulate  a 
Satellite/Terrestrial  Network  with  a  Network  Control  Center  (NCC) 
(7).  An  ESM  processor  can  perform  the  NCC  function,  and  the 
various  gateway  or  loop  links  can  simulate  the  satellite  or 
terrestrial  communication  links. 


The  tasks  associated  with  Satellite  Control  are  described  in  Table 
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Table  2-7  Satellite  Control  Tasks 

Task  Man-Months 

RTACS  Element  Interaction  Investigation  4 

RTACS  Element  Interaction  Simulation 
Implementation  4 

Distributed  RTACS  Software  Testing  on  4 

ESM 

NCC  Implementation  4 


Effort 

Research 

Software 

Software 

Software 


2.2  Simulation  Facility  Enhancement 


The  flexible  structure  of  the  ESM  Multiloop  Network  provides  the 
modeler  with  the  capability  to  perform  many  different  types  of 
experiments.  The  ESM's  simulation  capability  is  based  on  the 
characteristic  that  nodal  microprocessors  and  host  processors  are 
programmable.  Thus  even  very  simple  experimental  simulations  may 
required  a  significant  number  of  programs  to  be  written  and 
debugged  on  the  distributed  system.  The  enhancement  of  the  ESM  to 
expand  the  modeler's  capability  to  write  application  programs  will 
improve  the  utilization  of  the  system. 


2.2.1  Distributed  Operating  System 


The  ESM  nodal  microprocessors  currently  run  a  Distributed  Master 
Control  Program  (DMCP)  which  allows  data  to  be  passed  around  the 
network  so  that  heterogeneous  external  devices  can  communicate 
with  each  other.  The  BDS  and  LSI-11  microprocessors  of  loops  4 
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and  5  have  sufficient  processor  and  memory  capability  to  be  used 
as  general  purpose  microcomputers.  They  are  programmable  in 
higher  level  languages;  i.e.,  ALGOL  for  the  BDS  and  FORTRAN  IV  for 
the  LSI-11.  Since  loop  connected  terminals  can  be  ATTACHED  to  any 
node,  I/O  for  the  general  purpose  microcomputer  could  be  done  via 
the  loop. 

The  general  purpose  microcomputer  capability  would  require  the 
enhancement  of  the  DMCP  to  function  as  a  general  purpose  operating 
system.  The  Stack  Machine  Operating  System  on  the  B776  could 
be  used  on  the  BDS  microcomputers,  and  the  RT-11  Operating  System 
on  the  PDP11V03  could  be  used  on  the  LSI-11  microcomputers.  These 
operating  systems  require  a  disk.  Thus  for  this  application,  the 
operating  systemsmust  be  distributed  so  that  disk  I/O  would  be 
done  via  the  loop.  This  would  require  the  development  of  a  file- 
request  processor  and  file-server  processor  so  that  each  remote 
loop  4  and  5  microprocessor  can  do  disk  I/O  to  a  host  processor 
with  disk.  In  addition,  an  On-Line  Loading  capability  would  have 
to  be  provided  so  that  different  application  programs  can  be  run 
dynamically  on  loop  4  and  5  microcomputers.  These  programs  would 
be  stored  on  a  host  processor's  disk  and  loaded  to  the  remote 
microcomputer  via  the  loop  when  a  RUN  command  was  entered  on  the 
terminal  ATTACHED  to  the  remote  node. 

The  software  tasks  to  implement  a  distributed  operating  system 
would  include  the  enhancement  of  the  DMCP  for  use  of  a  remote 
processor  with  a  general  purpose  operating  system  such  that  disk 
I/O  is  done  via  the  loop.  Also  included  are  tasks  to  develop  the 


File-Server  program  to  handle  disk  I/O  from  remote  processors,  and 
an  On-Line  loader  program.  The  tasks  are  given  in  Table  2-8.  The 
man-month  estimates  given  are  for  an  implementation  on  loop  4  or 
loop  5.  Implementation  on  both  loops  would  require  duplicate 
coding  and  debugging  since  loop  4  is  programmed  in  ALGOL  and  loop 
5  is  programmed  in  FORTRAN. 


Table  2-8  Distributed  Operating  System  Tasks 


Task 


Man-Months  Effort 


DMCP  Enhancement  for  General 
Purpose  OS 

File-Server  Development 
On-Line  Loader  Development 


4  Software 
4  Software 
3  Software 


2.2.2  User  Interface  Enhancement 

The  User  Interface  to  the  ESM  should  be  enhanced  to  provide  infor¬ 
mation  to  the  inexperienced  user  and  additional  capability  to  the 
experienced  user.  A  resource  allocator  program  could  be  developed 
such  that  upon  login  system  users  will  be  informed  of  available 
simulation  facility  resources.  instructions  on  using  the 
resources  and  the  capability  to  ATTACH  to  the  resources  would  be 
provided.  The  displays  to  the  user  would  be  consistent  throughout 
the  system.  The  displays  would  be  easy  to  use  and  could  utilize 
the  forms  mode  capability  of  the  Burroughs  terminals?  a  cursor  can 
be  moved  in  a  menu-selection  type  of  display  to  select  resources. 
File  listings  can  be  scrolled  on  the  terminals. 
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An  enhanced  file  transfer  utility  can  be  developed  so  that  files 
can  be  transferred  between  all  ESM  host  processors.  A  minimal 
utility  currently  exists  ( LPFT )  for  transferring  files  between  the 
B776  and  the  PDP  11/40  processors.  Other  enhancements  would 
include  improved  loading  and  diagnostic  software,  and  a  Super¬ 
visory  Printer  Output  (SPO)  node  which  would  log  system  errors  and 
allow  the  operator  to  reconfigure  the  system  to  account  for  hard¬ 
ware  failures. 

Man-month  estimates  for  User  Interface  Enhancement  software  tasks 
are  given  in  Table  2-9. 

Table  2-9  User  Interface  Enhancement  Tasks 


Task 

Man-Months 

Effort 

Resource  Allocator  Development 

4 

Software 

File  Transfer  Utility  Development 

2 

Software 

Improved  Loading  Utility  Development 

1 

Software 

Improved  Diagnostic  Software 

3 

Software 

SPO  Program  Development 

4 

Software 

2.2.3  Equipment  Interfacing 

Since  the  heterogeneous  nature  of  the  ESM  allows  terminals  to 
ATTACH  to  any  processor  and  processors  to  communicate  with  each 
other,  it  would  be  advantageous  to  the  modeler  to  have  many 
different  resources  interfaced  to  the  ESM.  The  attachment  of  host 
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processors  to  the  ESM  is  relatively  straight-forward.  The  oper¬ 
ating  system  of  the  host  processor  is  not  modified*  instead  the 
nodal  microprocessor  is  programmed  to  emulate  a  terminal  connected 
to  the  host  processor.  In  this  manner  the  modeler  can  do  software 
development  on  many  different  machines  and  operating  systems.  The 
loop  connected  terminals  act  as  if  they  were  local  terminals 
connected  to  various  loop  connected  host  processors.  In  addition, 
using  the  loop  broadcast  capability,  a  terminal  can  input  commands 
to  two  or  more  loop  connected  processors  at  the  same  time.  This 
feature  would  bo  useful  for  developing  distributed  system  software 
where  machines  run  copies  of  the  sam  esoftware  except  for 
addresses . 

Another  useful  piece  of  equipment  that  could  be  interface  to  ESM 
would  be  a  node  controlled  line  printer.  The  line  printer  could 
be  used  by  all  host  processors  to  obtain  source  file  listings,  and 
as  a  monitor  for  displaying  system  error  messages. 

The  software  cost  estimate  for  interfacing  a  processor  or  line 
printer  to  ESM  is  two  man-months.  Necessary  hardware  would 
include  an  interface  card  and  cable  estimated  at  $200.  In  add¬ 
ition,  the  interfaced  equipment  would  have  to  be  supplied  or  made 
available  to  ESM. 
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2.2.4  Scenario  Generation 


It  would  be  useful  to  the  modeler  to  have  a  scenario  generation 
capability  for  experiments.  A  general  simulation  model  could  be 
developed  which  allows  experiments  to  be  defined  with  various  para¬ 
meters  and  provide  restart  points  for  extended  simulations.  An 
events  simulator  could  be  developed  to  provide  parameterized 
scenai ios  which  can  be  stored  on  disk  or  tape  and  used  to  provide 
simulated  inputs  to  the  system.  The  System  Control  Mode  3  of  the 
User  Language  on  Host  Processor  B  could  be  enhanced  so  that  LID/ 

FAD  conversion  table  values  for  all  nodes  corresponding  the 
various  experiments  can  be  loaded  on  command.  A  fault-box  simu¬ 
lator  panel  could  be  built  such  that  faults  may  be  introduced  to 
the  system  via  a  centralized  switching  panel. 

F.xpet  iments  comparing  centralized  vs.  distributed  System  Control 
operation  could  be  performed.  Comparisons  could  be  made  between  a 
program  running  on  a  single  minicomputer  and  distributed  on  mote 
than  one  minicomputer.  The  delay  times  and  overheads  could  be 
invest  igated . 

Table  2-10  describes  the  tasks  associated  with  Scenario 
Genet  at  ion . 
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Table  2-10  Scenario  Generation  Tasks 


Task 

General  Simulation  Model  Development 
Events  Simulator  Development 


Man-Months  Effort 


6 

4 


Software 

Software 


2.2.5  PDP  11/70  Application  Programs 

The  ESMD  project  demonstrated  the  feasibility  of  connecting  loop  4 
to  a  PDP  11/70  processor  by  programming  the  BDS  microprocessor  to 
emulate  a  VT52  DECScope.  The  PDP  11/70  could  be  enhanced  with 
additional  software  and  used  as  a  System  Control  host  processor  in 
the  ESM.  The  interface  displays  could  be  enhanced  so  that  the 
loop  connected  terminal  appears  more  like  the  local  DECScope  and 
becomes  easier  for  the  operator  to  enter  data.  A  demonstration 
was  performed  for  the  ESMD  Acceptance  Test  in  which  the  PDP  11/70 
monitors  a  CRT-B776  conversation  using  the  non-destructive  read 
capability  of  loop  4  and  5  nodes  in  order  to  function  as  a 
security  monitor  which  removes  the  CRT  from  the  network  when  a  bad 
password  is  detected.  This  security  monitor  function  can  be 
enhanced  and  studied.  Another  enhancement  would  be  to  use  the  PDP 
11/70  as  a  reliability  monitor  for  ESM  hardware.  Diagnostics 
could  be  performed  and  On-Line  and  Off-Line  configurations  could 
be  defined. 
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Man-month  software  estimates  for  PDP  11/70  tasks  are  given  in 
Table  2-11 


Task 


Table  2-11  PDP  11/70  Application  Programs 

Man-Months  Effort 


System  Control  Host  Processor 
Ut il izat ion 

Interface  Display  Enhancement 
Security  Monitor 
Reliability  Monitor 


Software 

Software 

Software 

Software 


2.3  Distributed  System  Control  Investigation  Areas 


The  ESM  could  be  used  as  a  Research  and  Development  tool  to  study 
various  characteristics  of  a  distributed  processing  system.  In 
particular  the  problems  involved  with  a  distributed  System  Control 
architecture  can  be  investigated. 


2.3.1  Distributed  Operating  System  for  Multiprocessing 

The  effects  of  a  multiprocessor  environment  on  the  System  Control 
function  can  be  investigated  on  loops  4  and  5.  Especially 
important  would  be  experiments  related  to  the  impact  of  a  multi¬ 
processor  configuration  on  processing  speed  and  functional  module 
decomposition.  Experiments  could  be  designed  for  measuring  the 
processing  time  needed  to  support  inter  processor  interactions  and 
the  full  extent  of  inter processor  communications  requirements  as  a 
function  of  module  decomposition. 
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|  Distributed  Operating  Systems  could  be  mapped  on  the  ESM  hardware 

and  investigated.  The  amount  of  overhead  involved  with  inter¬ 
processor  communications  as  a  function  of  the  degree  of  coupling 
can  be  studied.  The  advantages  and  disadvantages  of  a  distributed 
multi-microprocessor  architecture  versus  a  single  minicomputer 
architecture  can  be  studied  by  comparing  the  execution  of  software 
running  on  one  minicomputer  with  a  distributed  version  of  the  soft¬ 
ware  running  on  many  microcomputers  with  a  distributed  operating 
system . 

The  tasks  associated  with  a  Distributed  Operating  System  for 
Multiprocessing  are  given  in  Table  2-12. 

Table  2-12  Distributed  Operating  System  for 
Multiprocessing  Tasks 


Task 

Man-Months 

Effort 

Distr ibuted 

Operating 

System  Design 

7 

Research 

Distributed  Operating 
Implementation  on  ESM 

System 

7 

Software 

Measurement 

Implemented 

and  Evaluation  of 

System 

5 

Research 

2.3.2  Network  Architectures 

The  ESM  can  be  used  to  study  network  architectures.  Experimen¬ 
tation  can  be  performed  with  different  network  protocols  suitable 
for  the  System  Control  environment.  System  Control  architectures 
can  be  simulated  on  the  Multiloop  Network  in  order  to  check  for 
inadequacies  in  network  protocols  at  each  layer  of  the  network. 


b 
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Expet iments  compat ing  centralized  vs.  distributed  System  Control 
operation  could  be  performed.  Comparisons  could  be  made  between  a 
program  running  on  a  single  minicomputer  and  distributed  on  more 
than  one  minicomput er .  The  delay  times  and  overheads  could  be 
invest igated . 

The  connection  of  the  ESM  to  additional  DCAHSF  host  systems  can  be 
used  for  larger  scale  System  Control  network  architecture  studies. 
This  connection  will  provide  additional  processing  and  storage 
resources  for  examining  larger  data  bases,  more  System  Control 
hierarchical  levels,  and  additional  programming  languages,  oper¬ 
ating  systems  and  utilities.  The  addition  of  a  loop  node  connect¬ 
ed  line  printer  would  provide  hard  copy  printout  capability  to  all 
nodes  in  the  system.  Measurement  equipment  could  be  connected  to 
loop  5  using  the  IEEE  Standard  488-1975  Digital  Interface  for 
Programmable  Instrumentation  (via  IBV11-A  interface  -  Node  27). 

Table  2-13  describes  the  tasks  associated  with  the  study  of  Net¬ 
work  Architectures. 

Table  2-13  Network  Architecture  Tasks 


Task 

Man-Months 

Ef for t 

Ident  i  f icat ion 
Arch  itectur  es 

of 

Networ  k 

3 

Research 

Ident  if icat ion 
Pr  otocols 

of 

Networ  k 

5 

Research 

Implementat ion 

of 

Protocols  on 

ESM  5 

Sof  twar  e 

Evaluation  and 

Conclusions 

3 

Research 
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2.3.3  Throughput  Analyses 


The  ESM  can  be  used  to  perform  network  throughput  and  response 
time  analyses.  Netwoi k  overload  simulations  could  be  performed  by 
generating  excessive  traffic  by  processors.  Delay  times  and  queue 
sizes  at  various  loop  operating  speeds  could  be  displayed  and 
studied.  The  effect  of  emergency  messages  attempting  to  penetrate 
an  overloaded  netwoi k  could  be  examined.  Mathematical  models 
could  be  developed  and  verified  by  the  simulation  results.  Trace 
messages  could  be  generated  and  displayed  that  monitor  queue 
sizes,  arrival  and  departure  times,  and  nodes  traversed  as  they 
are  sent  from  a  source  node  to  a  sink  node. 


Table  2-14  describes  the  tasks  associated  with  Throughput 
Analyses. 


Table  2-14  Throughput  Analyses  Tasks 


Task 

Man-Months 

Effort 

Mathematical  Model  Development 

4 

Research 

Network  Traffic  Simulator  Software 
Development 

3 

Software 

Trace  Message  Detection  Software 
Development 

3 

Software 

Evaluation  and  Conlusions 

3 

Research 
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2.3.4  Security 


Experiments  could  be  performed  to  study  the  effects  of  distribut¬ 
ing  LID  and  node  controller  functions  as  described  in  Section  3 
(Security)  of  the  ESMD  Final  Report  (8).  Experiments  could  be 
performed  in  the  areas  of  N'th  party  authorization  problems  in  a 
networking  environment,  distributed  logon  procedures  and  security 
monitoring/auditing  procedures.  The  estimated  cost  of  security 
related  tasks  is  18  man-months. 


- 
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APPENDIX  A 


GLOSSARY  OF  ACRONYMS 

The  interdi sciplinary  nahure  of  the  present  study  is  emphasized  by 
the  large  number  of  different  acronyms,  from  diverse  sources,  that 
appear  in  the  discussion.  The  following  is  a  partial  list  of  some 
of  the  relevant  acronyms  that  have  been  identified.  It  also 
serves  as  a  glossary. 

AC AS  AUTOVON  Centralized  Alarm  System 

ACOC  Area  Communications  Operations  Center 

ADM  Adaptive  Delta  Modulation 

ADO  Burroughs  Advanced  Development  Organization 

ASC  Automatic  Swtiching  Center  (AUTODIN) 

ASCII  American  Standard  Code  for  Information  Interchange 
ASCC  AUTODIN  Station  Control  Console 

ASSC  AUTODIN  Station  Supervisory  Console 

ASU  Alarm  Scanner  Unit 

ATEC  Automated  Tech  Control 

AVIE  AUTOVON  Information  and  Evaluation  Network 

BARS  Buffered  Automatic  Reporting  System 

BBSA  Baseband  Signal  Analysis 
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BDLC 


Burroughs  Data  Link  Control 
BLIUI  Bus  Loop  Interface  Unit  Interface 

BWBSA  Combined  functions  of  BBSA  and  WBSA 

CCI  Command  and  Control  Interpreter 

CPU  Central  Processor  Unit 

CRT  Cathode  Ray  Tube 

DCA  Defense  Communications  Agency 

DCAOC  Defense  Communications  Agency  Operations  Center 

DCEC  Defense  Communications  Engineering  Center 

DCS  Defense  Communications  System 

DBMS  Data  Base  Management  Service 

DDMS  Digital  Distortion  Monitoring  Subsystem 

DMA  Direct  Memory  Access 

DSQC  Digital  Service  Quality  Control 

ESM  Exploratory  System  Control  Model 

ESMD  Exploratory  System  Control  Model  Development. 

FDM  Feasibility  Development.  Model 

FIAC  Fault  Isolation  and  Analysis  Coordination 

10  Input/Output 

LA- 36  DEC  Hard  Copy  Terminal 

LIU  Loop  Interface  Unit 

MSCDM  Modular  System  Control  Development  Model 

OCRI  Operator  Control  and  Report  Interface 

PDU  Program  Development  Unit 

PROM  Programmable  Read  Only  Memory 
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